Android 蓝牙开发 ᚼᛒ (一)
接触 Android 蓝牙开发已经有一段时间了，Android 官方文档虽然对蓝牙 API 介绍很详尽，但是对蓝牙协议不太了解的开发人员来说还是不足以建立一个系统的认识，当时和硬件组的小伙伴交流的时候这点带来的问题就特别明显。网上的资料少，并且良莠不齐，于是去 SIG 官网找了协议文档（七大卷，真的厚…)，查阅之后，厘清了很多概念，大致了解了整个系统轮廓。
接下来会从蓝牙协议和 Android 蓝牙开发这两部分来叙述。
这是第一篇，蓝牙协议。
什么是蓝牙
蓝牙是一种短距离的短波无线通信技术，目前主要分为基础率/增强数据率（BR / EDR）和低功耗（LE）两个版本，前者通常也称为经典版蓝牙。
关于蓝牙这个名称的由来，蓝牙的发展历史及各版本的比对等基本信息在蓝牙的维基百科词条上写得很详细，就不再赘述。
蓝牙的架构
蓝牙4.0是一个综合协议规范，它除了提出了新的 LE 规范，还囊括了 BR / EDR 规范，并在实际使用中分为了单模(Single mode)和双模(Dual mode)版本，前者仅支持 LE 规范且不能和蓝牙4.0之前的版本通信，后者同时支持 LE 和 BR / EDR 规范，并且兼容旧版蓝牙。
本文关于蓝牙协议栈的分析均基于蓝牙4.1
下图是根据蓝牙 4.1 核心技术栈及部分应用协议绘制的蓝牙协议栈示意图
*上图仅供参考，详细架构图参见 SIG 蓝牙协议文档
蓝牙协议栈主要由主机 (Host)、控制器(Controllers) 和主机控制器接口(Host Controller Interface, HCI) 三部分组成。
我们先以两个直观的表述来感受这三部分与我们现实设备的对应关系。
对于没有蓝牙的PC，我们通常可以淘宝买一个USB蓝牙适配器来为PC增加蓝牙功能。这里的蓝牙适配器可以理解为Controllers，PC 可以理解为 Host，USB 的连接方式就是一种 HCI。
我们的手机上的蓝牙模块也可以这样对应，手机操作系统就是Host，Controllers就是主板上的蓝牙芯片，PCB 板上连接 CPU 和蓝牙 IC 的 UART，也是一种HCI。
当然，以上表述并不严谨，实际上 Host 层是硬件的抽象，而与具体的硬件无关，控制器是协议栈的底层实现，它才与硬件直接相关，通常就是蓝牙 IC。
前文图中展示的仅是一个通用的蓝牙架构图，我们手机上的双模蓝牙系统与之类似，但实际上一个蓝牙设备可以仅由一个 Host 和一个主控制器组成，HCI 层其实是可选的，在具有简单功能的蓝牙设备（例如耳机）中，Host 和控制器可以在同一微处理器上实现, 而无需 HCI。
主控制器可以是以下三种：
- BR / EDR 控制器
- LE 控制器
- BR / EDR 和 LE 组合控制器
可选的还可以有一个或多个次要控制器(AMP)，AMP 在蓝牙 3.0 就已经引入，主要和 BR / EDR 搭配使用，作为数据高速传输通道。这种场景下，BR / EDR 主要用作搜索，配对，连接建立和连接维持的作用。当两个 BR / EDR 蓝牙设备 L2CAP 连接建立后，AMP 管理器能检测到另外一个设备的AMP管理器。当两个蓝牙设备都有 AMP 控制器，蓝牙核心系统提供这样一种机制，能让数据流从主控制器迁移到次要控制器，即通过 AMP 来传输，AMP 可以使用 802.11 协议转换层(PAL) 來提供更高的傳輸率，最高可达 54 Mbps。
结合以上，关于实际的蓝牙设备架构，我们可以组合几种控制器和 Host 得到以下符合规范的蓝牙架构：
- 四种可能的单模架构
- 三种可能的双模架构
控制器和 HCI 涉及底层硬件部分，不做更多讨论，接下来重点对 Host 层做一个具体的说明。
Host
Host 包含逻辑链路控制和适配层(Logical Link control & Adaption Protocol, L2CAP) 以及图中未画出的 Channel Manager、Security Manager Protocol (SMP) 和图中出现的 GAP等其他更高层。L2CAP主要起到数据缓冲和简单数据管理的作用。通道管理器负责创建，管理和关闭用于传输服务协议和应用程序数据流的L2CAP通道。SMP等其他部分详情参见核心协议文档，我们把重点放到应用层。
Profiles
蓝牙系统中的应用程序互操作性（应用部分）由各种蓝牙配置文件（Profile）完成。
Profile 就是定义了一个实际的应用场景。具体来说，Profile 定义了蓝牙系统中从PHY（物理层）到 L2CAP 的每层以及核心规范之外的任何其他协议所需的功能和特性。应用的行为和数据格式也由 Profile 定义。当两个蓝牙设备都符合某一种配置文件 的所有要求时，即可开启并执行对应的应用操作。需要特别说明的是，LE 的Profile 和 BR / EDR 的并不兼容，前文中的蓝牙架构图里展示出的几个Profile例子中，蓝色背景的是 BR / EDR 特有的Profile。
蓝牙规范中定义了很多常用的 Profile，在 4.0 中引入的 GATT / ATT 让我们可以创建新的 Profile。 下面介绍一些常用的配置文件
GAP
GAP，即通用访问配置文件，所有蓝牙设备都必须实现的基本配置文件。 它定义了蓝牙设备的基本要求，例如，对于 BR / EDR，它定义了蓝牙设备以包括无线电，基带，链路管理器，L2CAP 和服务发现协议功能; 对于 LE，它定义了物理层，链路层，L2CAP，安全管理器，GATT / ATT。这将所有各层连接在一起，形成蓝牙设备的基本要求。它还描述了设备搜寻，连接建立，安全性，身份验证，关联模型和服务搜寻的行为方法。
在BR / EDR中，GAP定义每个设备为单一角色，其可能具备的功能包括设备如何相互发现，建立连接以及描述用于身份验证的安全关联模型。设备可能只具备其中一种或多种功能，比如只具有启动或接受连接功能。
在 LE 中，GAP 定义了四个特定角色：Broadcaster，Observer，Peripheral 和 Central。如果底层 Controller 支持这些角色或角色组合，则设备也可同时支持多个角色。但是，在某一时刻只能支持其中一个角色。每个角色都指定了底层Controller的要求。这允许控制器针对特定用例进行优化。
LE 的 Profiles
如上所诉，LE 让我们可以创建自己的 Profile，当然需要遵循一定的规范，这个规范就是 GATT / ATT
GATT / ATT
通用属性配置文件（GATT）构建在属性协议（ATT）之上，并为属性协议传输和存储的数据建立通用操作和框架。GATT 和 ATT 通常在 LE 中实现。
是的，GATT 和 ATT 还可以在 BR / EDR 中实现，蓝牙 4.1 核心系统协议中对 GATT / ATT 的表述是：“GATT和ATT不是特定于传输层的，其可用于BR / EDR 和 LE。而在 LE 中 GATT / ATT 用于搜寻服务，因此是必须实现的” (from core_SPEC_vol1_6.4)
GATT 定义了两个角色：服务端和客户端。 GATT 角色不一定与特定的 LE GAP 角色相关联，但可以由更高层的配置文件指定。GATT 服务器发送对请求的响应，并在配置时，在GATT服务器上发生指定事件时，向GATT客户端异步发送指示和通知。
GATT 按照层级定义了三个概念：服务（Service）、特征（Characteristic）和描述（Descriptor）。他们的包含关系如下图所示：一个 Service 包含若干个 Characteristic，一个 Characteristic 包含若干 Descriptor。Characteristic 定义了数值和操作。把若干个相关的 Service 组合在一起，就成为了一个 Profile。
BR / EDR 的 Profiles
虽然 BR / EDR 的配置文件都是在蓝牙2.0、 3.0 的时候设计的，但仍是目前蓝牙“大”流量数据传输的主要方式。比如硬件调试常用的串口通信（SPP），蓝牙耳机听歌用的 A2DP 协议，文件传输（FTP）等。
SPP
Serial Port Profile，即串口配置文件，定义了使用蓝牙进行 RS232（或类似）串口仿真的协议和过程。这也是蓝牙诞生之初的主要功能：替代 RS232 有线通信，以无线的方式链接多个设备，克服同步问题。
SPP 协议栈示意图：
图源: SIG - SPP_SPEC_V12
SPP 是基于 RFCOMM 通信协议的规范，RFCOMM 是一种简单的传输协议，其实也是用于仿真RS-232（ITU-T V.24）串口通信。RFCOMM支持在两个设备之间模拟多个串口，或者在多个设备之间模拟串口，最多支持 两个设备间 60 个串口的同时连接。SPP 可以视为仅是对 RFCOMM的简单封装。
A2DP
官方描述：
高级音频分发配置文件（A2DP）定义了在 ACL 通道上实现单声道或立体声高质量音频内容分配的协议和程序。典型的使用情况是将音乐内容从立体声音乐播放器流式传输到耳机或扬声器。音频数据以适当的格式压缩，以有效利用有限的带宽。环绕声分布不包含在此配置文件的范围内。
上面提到的“适当的格式”也就是网上很多蓝牙音质讨论帖中提到的SBC、Aptx等编码格式。
此配置文件定义了以下角色：
源 Source（SRC）
传送数字音频流到微微网SNK端。
接收器 Sink（SNK）
更多的 BR / EDR Profiles 和协议可以参考 SIG官网